AWS Network FirewallとTransit Gatewayを合わせて使う #cmregrowth
先日行われた re:Growth 2020 Online インフラ特別号〜AWS re:Invent 振り返り勉強会〜 で AWS Network FirewallでSquidを滅ぼす AWS Network FirewallでSquidを滅ぼそうとしたらTransit Gatewayがムズすぎた というテーマで発表を行いました。
AWS Network Firewallの概要やルーティングについておさらいして、Transit Gatewayを用いた大きい環境の集約方法などについてご紹介する内容となっています。
登壇中にポインターを利用して解説している部分があり、スライドだけ見ても良く分からない点があると思いますので、ブログ形式でご紹介します。
AWS Network Firewall概要
AWS Network Firewall(以降Network Firewall)はマネージドなNetwork Firewallです。これまでSquidなどでアウトバウンド通信を制御していた環境などNetwork Firewallを利用することで、Squidの運用をする事無く、ネットワークのファイアウォールを管理出来るようになります。
シンプルな構成の場合のルーティング
Network Firewallを理解するためには、まずルーティングを理解する必要があります。
下記構成図はNetwork Firewallの構成図ですが、Internet Gatewayの経路(VPC Ingress Routing)や、VPC Endpointなどがあり、ぱっと見だと理解しがたいかもしれません。
今回は「EC2からアウトバウンド通信をする」例で、順を追って説明してみます。
インバウンド
まず、EC2からインターネットへ出たい場合、 Protected Subnetのルートテーブルの0.0.0.0/0 vpce-idを見て、VPC Endpointに行きます。
ここで出てくる vpce-id は「Network FirewallのVPC Endpoint」となっており、もう少し具体的に言うと、「Network Firewallが内部的に利用しているGateway Load BalancerのVPC Endpoint」で、Network Firewallをプロビジョニングする際に指定したサブネットにVPC Endpointを生やすことができます。
VPC Endpointへ来た通信は、一旦Network Firewallへ行きます。
Network Firewallではルールと照らし合わせて、OKだった場合、再度VPC Endpointに戻します。このとき、定義しているルールと一致する物があった場合、Dropされます。
そして、VPC Endpointがある「Firewall Subnet」のルートテーブルを見ると、 0.0.0.0/0 igwとありますので、このままIGWへ抜けていきます。
アウトバウンド
インターネットからの通信はどうなるでしょうか。
まず、IGWのルートテーブル(VPC Ingress Routing)を見て、10.0.0.0/24 vpce-id、つまり、EC2があるサブネットへの通信の場合はVPC Endpointに流すような経路になります。
ここでVPC Endpointに来た通信はインバウンドの時と同じようにNetwork Firewallに流れ、インターネットからの通信についてもNetwork Firewallで検査されて
EC2に流れます。
VPC Ingress Routing / Gateway Load Balancer
ここで割と最近にGAされた、機能について振り返っておきましょう。
VPC Ingress Routingは、超ざっくり簡単に言うと「インターネットゲートウェイのルートテーブル」です。今回の場合ですと、10.0.0.0/24(Protected Subnet)への通信をVPC Endpointへ流すように設定して利用しています。
Gateway Load BalancerはNetwork FirewallとVPC間の通信に利用されます。
Gateway Load Balancerの特徴として、 Geneve(Generic Network Virtualization Encapsulation)を利用するためNATせずに（元のトラフィックを加工せずに）流すことができます。
どちらも最近出てきたアップデートですので、合わせてキャッチアップしていきましょう。
Network Firewallで設定できること
ルーティングの話ばかりで遅くなりましたが、Network Firewallで出来ることはざっくり下記スライドの通りです。
基本的にはStateFul Rule Groupをメインで扱う事になるかと思います。
Network Firewallそのものの機能などについてはこちらの記事にて記載されておりますので合わせてご確認ください。
SingleAZのシンプルな構成を作ってみる
実際に経路の紹介でお話ししたような構成を作ってみました。一旦はNetwork Firewallのルールは無しで作成しています。
ここで一点重要なのが、「EC2はPublic IPが必要」な点です。当たり前ですが、Network FirewallではNATなどを行わないため、インターネットに出る際はIPアドレスが必要となります。
もちろん、EC2にEIPを付けて利用する事もできますが、NAT Gateway用のサブネットを用意してNAT Gateway経由でNetwork Firewallを通してインターネットに出ることもできます。
接続確認をしてみましょう。EC2にSSHすると正常にSSHをする事ができ、ルール設定を行っていないためexample.comへの通信も通ります。
ここでStateful Ruleを投入して、example.comへの通信をDenyしてみましょう。
example.comへの通信が出来なくなっていることを確認できます。
Transit Gatewayを組み合わせて使うパターン
お待たせしました、やっと本編です。
AWSの公式ブログ Deployment models for AWS Network Firewall ではNetwork Firewallを使う方法として大きく分けて3つのパターンを紹介しています。
この3つのパターンですが、Network Firewallの概要を含めて理解するまでに4時間くらい掛かってしまったので、10分程度でサマって解説していきます。
Distributed AWS Network Firewall deployment model
Distributed AWS Network Firewall deployment modelは、各VPCにNetwork FirewallをDeployするモデルとなります。
各VPCにデプロイしますので、冒頭に出てきた構成を横に並べているだけで、特に難しい事もないです。
この構成が一番シンプルとなりますが、下記の2点を留意しておく必要があります。
- この構成図だとVPC Peeringやオンプレミスとの接続がないため、接続する場合は内部通信の扱いを検討する必要がある。
-
Network Firewallは1エンドポイント $0.395/h で、2AZ構成になると2エンドポイントとなり、横に並べるVPCの数が増えるにつれて料金が高くなる。
Centralized deployment model
Centralized deployment modelでは、Transit Gatewayを用いて、名前の通り一元的な検査用VPCを用意して、トラフィックを検査するパターンになります。
Transit Gatewayがいきなり出てきて、わちゃっとしていますが、要点を押さえて解説していきます。
まず、EC2からインターネットへ抜けていく場合、これは下記のような経路で抜けていきます。
- Spoke VPC A(左上)の 0.0.0.0/0 tgw でTransit Gatewayへ
- Transit GatewayのSpoke Inspection Route Tableで 0.0.0.0/0 Inspection VPC(右上)へ
- Inspection VPC(右上)でNetwork Firewallに行き、Network Firewallの判定がOKだった場合、0.0.0.0/0 tgw でTransit Gatewayに戻す
- Transit GatewayのFirewall Route Tableで0.0.0.0/0 Central Egress VPC(右下)へ
- Central Egress VPCのTGWサブネットのルートテーブルでNAT Gatewayを指定
- NAT GatewayでNATされてInternet Gatewayからインターネットへ抜ける
といった流れになります。（長い）
図に起こすとこんな感じになります。
帰りについてもNetwork Firewallを通る形となっています。
- 帰りは10.0.0.0/8 tgwでTransit Gatewayに戻り
- Spoke Inspection Route Tableを見てInspection VPCに行き
- Inspection VPCに検査されてTransit Gatewayに戻され
- Firewall Route Tableの10.1.0.0/16の経路でEC2に戻る
また、Spoke Inspection Route Tableでは0.0.0.0/0をInspection VPCに流す動作をするため、Spoke Inspection Route TableをAssociationしているVPCやDirect Connect、VPN環境も合わせて検査できます。
続いてSpoke VPC Aにあるアプリケーションを外部に公開する事を想定して、ALBを叩いたときの流れを見てみましょう。
これは既に構成図に引かれている線がありますので矢印は簡略させて頂きます。
ALBはリバースプロキシのような挙動をしますので、EC2からのレスポンスはALBのPrivate IP(10.11.1.9/24)に正常に流れる形となります。
Combined centralized and distributed deployment model
CentralizedとDistributed二つのパターンを組み合わせて、一部VPCは自前でNetwork Firewallを持ち、IngressとEgressは独立したNetwork Firewallで構成されるパターンです。
Transit GatewayのSpoke Route Tableを見て頂くと分かるとおり、10.0.0.0/8(AWS環境)と192.168.168.0/24(オンプレミス環境)だけをInspection VPC、それ以外(0.0.0.0/0)をCentral Egress VPCに流すことにより、Network Firewallを分けていることを確認できると思います。
また、必要であればSpoke VPC BのようにIngressの口を開くことも出来ますので、「このVPCの通信だけはルール除外したい」などの場合で柔軟に組めるのがこの構成となっています。
Network Firewall + Transit Gateway設計の留意点
Network Firewall + Transit Gatewayの構成を取る場合、何点か注意点があります。
- CIDRが被らない事(あたりまえ)
- Transit GatewayのAttach用サブネットを作ること(/28)
- Network FirewallはENI1個できるだけなので /28のサブネットを作ればOK
- 構成図は簡略化のためにSingleAZとしているが、実環境では複数のAZを使う
- AZの数(Network FirewallのEndpointの数)だけ料金が掛かるので注意
- トラフィックに対して完全に透過でNATを行わない(追記)
- 必要に応じてNAT Gatewayを配置する
ELBのIngress集約については後日検証してブログにてご紹介致します。
まとめ
Network Firewallはネットワークの門番です。マネージなのでSquidなどのProxyを運用をしなくてもフィルタリングを行えますし、Suricate IPS互換ルールに対応していますので、既に利用している製品からのマイグレーションも出来ます。
良くも悪くもトラフィックに対して完全に透過なので、NATを行わない点に注意が必要です。必要に応じてNAT Gateway等を利用してあげましょう。
また、Transit Gatewayと合わせて使うと自由に設計が出来るサービスですが、経路の設計が難しい点に注意が必要です。
まだ東京リージョンでは使えないので、東京リージョン対応待ってます！！！！！！！
以上、もこでしたー。
